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APPEAL BRIEF 

Sir: 

This Appeal Brief is submitted in support of the Notice of Appeal filed on January 
28, 2005, and corrects and replaces the allegedly defective Appeal Brief that was filed on 
March 10, 2005. 

L REAL PARTY IN INTEREST 

Sun Microsystems, Inc. is the real party in interest. 

II. RELATED APPEALS AND INTERFERENCES 

U.S. Patent Application Serial No. 09/483,724 is related to the present application 
and is currently under appeal before the Board of Patent Appeals and Interferences. 
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III. STATUS OF CLAIMS 

Claims 1 1-23, 34-46, and 57-105 are pending in this application, have been 
finally rejected, and are the subject of this appeal. 

IV. STATUS OF AMENDMENTS 

No amendments were filed after the Office Action mailed on October 28, 2004. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present application contains independent Claims 1 1, 34, and 57. These 
independent claims recite similar Hmitations, except in the context of a method, a 
framework, and a computer-readable medium, respectively. Claims 1 1, 34, and 57 are 
directed generally to an object-oriented approach for dynamically constructing 
customized implementations to enforce restrictions on services. For purposes of the 
present invention, a service is defined broadly to encompass any functionality requested 
by and provided to an application, including but not limited to encryption/decryption 
functionality. 

According to the approach recited in Claims 1 1, 34, and 57, a fi-amework 
receives, fi-om an application, a request for an implementation of a particular service, 
such as an implementation of a particular encryption algorithm. In response, the 
framework determines what restrictions, if any, need to be imposed on the requested 
implementation. Once the restrictions are determined, the framework dynamically 
constructs the requested implementation. The requested implementation is constructed 
such that it incorporates the general (i.e. unrestricted) implementation of the service, the 
restrictions, and enforcement logic for enforcing the restrictions on the general 
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implementation. Since the requested implementation is constructed specifically for the 
application, it is customized for the application. Thus, the implementation is referred to 
as the customized implementation. 

The framework instantiates a wrapper instance as a part of dynamically 
constructing the customized implementation. The wrapper instance comprises 
enforcement logic for enforcing the restrictions. The framework then encapsulates both 
the restrictions and an instance of the general implementation within the wrapper 
instance. The wrapper instance ensures that the restrictions are enforced. 

Once the encapsulation process is complete, the framework provides the newly 
constructed wrapper instance to the application that requested the customized 
implementation. The wrapper instance is provided as the customized implementation 
requested by the application. Due to the mapping of the methods of the wrapper instance 
to the proper methods of the general implementation instance, the application may invoke 
the methods of the wrapper instance in the same manner as the application would have 
invoked the methods of the general implementation instance. Consequently, the 
application does not need to be modified to handle the wrapper instance differently than 
the general implementation instance. 

Since the customized implementation incorporates the restrictions and 
enforcement logic for enforcing the restrictions, it is not necessary for the application to 
fiirther interact with the framework. The customized implementation itself will provide 
the services, and will guarantee that the restrictions are enforced. By dynamically 
constructing customized implementations in this manner, the framework ensures that the 
necessary restrictions are enforced on the services provided to the application 
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(Specification, at page 2, lines 23-25, page 3, lines 1-25, page 14, lines 6-25, page 15, 

lines 1-4, FIG. 2, and FIGS. 4A-B). 

More specifically. Claim 1 1 recites (with reference annotations in parenthesis): 
In a system (FIG. 1, 100) comprising an application (FIG. 1, 104), a framework 

(FIG. 1, 102) and an implementation class (FIG. 1, 106) which provides an 

implementation for a particular service, a method performed by the framework, 

comprising: 

receiving (FIG. 4A, 404; page 10, line 24 to page 1 1, line 6) a request from an 
application for a customized implementation of a particular service; 

instantiating (FIG. 4A, 428; page 12, lines 4-7) an implementation class (page 10, 
lines 2-6) which provides an implementation for the particular service (page 6, lines 16- 
1 8) to give rise to an implementation instance; 

determining (FIG. 4A, 436; page 12, lines 14-24) a set of zero or more restrictions 
to be imposed on said customized implementation; 

instantiating (FIG. 4B, 448; page 14, lines 12-13) a wrapper class (FIG. 3A, 306) 
to give rise to a wrapper instance, said wrapper instance comprising enforcement logic 
(page 15, line 21 to page 16, line 4) for enforcing said restrictions; 

encapsulating (FIG. 4B, 452; page 14, lines 13-16) said implementation instance 
and said restrictions within said wrapper instance; and 

providing (FIG. 4B, 456; page 15, lines 1-4) said wrapper instance to the 
application as said customized implementation; 

wherein said wrapper instance comprises one or more invocable methods (FIG. 
3A, 306; page 14, lines 16-25), wherein said implementation instance comprises one or 
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more invocable methods (FIG. 3B, 312; page 14, lines 16-25), and wherein encapsulating 
comprises: 

mapping (page 14, lines 16-25) the one or more invocable methods of said 
wrapper instance to the one or more invocable methods of said implementation instance. 

Independent Claims 34 and 57 recite corresponding features described at the same 
locations in the application. The dependent claims are not argued separately from the 
independent claims upon which they depend. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Claims 11, 12, 15, 18, 19, 34, 35, 38, 41, 42, 57, 58, 61, 64, 65, 70-80, 83- 
89, 92-98, and 101-105 stand rejected under 35 U.S.C. §103(a) as being allegedly 
unpatentable over Taylor, "Object-Oriented Information Systems" ("Taylor") in view of 
Pressman, "Software Engineering: A Practitioner's Approach." ("Pressman"). 

2. Claims 13, 14, 16, 17, 20-23, 36, 37, 39, 40, 43-46, 59, 60, 62, 63, 66-69, 
81, 82, 90, 91, 99, and 100 stand rejected under 35 U.S.C. 103(a) as being allegedly 
unpatentable over Taylor in view of Pressman and Shanton, U.S. Patent No. 5,369,702 
("Shanton"). 

VIII. ARGUMENTS 

A. Introduction 

It is well founded that to establish a prima facie case of obviousness under 35 
U.S.C. § 103(a), the references cited and rehed upon must teach or suggest all the claim 
limitations. 
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With respect to the present application, it is respectfiilly submitted that Taylor and 
Pressman, considered alone or in combination, do not teach or suggest all the limitations of 
Claims 11, 12, 15, 18, 19, 34, 35, 38, 41, 42, 57, 58, 61, 64, 65, 70-80, 83-89, 92-98, and 
101-105. 

It is also respectfully submitted that Taylor, Pressman, and Shanton, considered 
alone or in combination, do not teach or suggest all the limitations of Claims 13, 14, 16, 17, 
20-23, 36, 37, 39, 40, 43-46, 59, 60, 62, 63, 66-69, 81, 82, 90, 91, 99, and 100. 

B. The Limitations of Claims IK 12. 15, 18, 19. 34. 35. 38, 41, 42, 57, 58, 6L 64. 
65, 70-80, 83-89, 92-98, and 101-105 Are Not in Any Way Taught or 
Suggested by Taylor and Pressman 

Claim 1 1 addresses the problem of how to ensure that restrictions are enforced on 
an implementation of a service that is plugged in to a framework. According to the 
approach recited in Claim 1 1 , the framework receives, from an application, a request for 
a customized implementation of a particular service. The framework instantiates an 
implementation class. The implementation class provides an implementation for the 
particular service. The instantiation of the implementation class gives rise to an 
implementation instance, which comprises one or more invocable methods. The 
framework determines a set of restrictions to be imposed on the customized 
implementation. 

The framework instantiates a wrapper class. The wrapper class comprises 
enforcement logic for enforcing the restrictions. The instantiation of the wrapper class 
gives rise to a wrapper instance, which also comprises one or more invocable methods. 
The framework encapsulates the implementation instance and the restrictions within the 
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wrapper instance. In doing so, the framework maps the invocable methods of the 
wrapper instance to the invocable methods of the implementation instance. The 
framework provides the wrapper instance to the application as the customized 
implementation. Because the wrapper instance comprises logic for enforcing restrictions, 
and because the restrictions are encapsulated within the wrapper instance along with the 
implementation instance, the customized implementation will provide the particular 
service, and restrictions on that particular service will be enforced. 

Summary of Examiner 's Contentions 

Li rejecting Claim 1 1, the Examiner contends that Taylor and Pressman disclose 
the above features. The Examiner alleges that Taylor discloses a wrapper instance on 
page 296. The Examiner asserts that the rest of the features of Claim 1 1 are merely 
object-oriented programming and design principles, and are common knowledge within 
the art. The Examiner asserts that at least some of these principles are disclosed in 
Taylor, Pressman, or both. However, with the exception of the "wrapper instance," the 
Examiner does not specifically indicate the locations at which each feature of Claim 1 1 is 
allegedly disclosed, or even which reference allegedly discloses that feature. 

Appellant's attorney interviewed the Examiner by telephone on January 24, 2004 
in an attempt to obtain clarification of the Examiner's position. Appellant's attorney 
asked the Examiner specifically where, in the references, the following features of Claim 
1 1 were disclosed: the framework that performs the steps of Claim 1 1, the step of 
determining a set of restrictions to be imposed on a customized implementation, and the 
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concept that a wrapper instance comprises enforcement logic for enforcing those 
restrictions. 

During the interview, the Examiner expressed his opinion that, because 
everything recited in Claim 1 1 was allegedly common knowledge, he should not have to 
point out with specificity exactly which reference, and exactly where in that reference, 
each feature of Claim 1 1 was allegedly disclosed. The Examiner opined that the 
"fi-amework" of Claim 1 1 corresponds to any well-known operating system. The 
Examiner opined that, by virtue of instantiating a derived class that inherits firom a base 
class and that adds methods and properties that the base class does not possess, such an 
operating system determines a set of restrictions to be imposed upon the base class. The 
Examiner opined that, by virtue of the additional methods and properties that an instance 
of such a derived class contains, such an instance comprises enforcement logic for 
enforcing the restrictions. 

The merits of the Examiner's position are discussed below. 

Arsruments 

Appellants agree that a derived class may contain methods and properties that a 
base class upon which the derived class is based does not contain. However, the addition 
of these methods and properties to the derived class does not "restrict" the base class in 
any way. Such methods and properties do not appear in any way to prevent the usage of 
functionality that was available in the base class. Actually, the addition of such methods 
and properties to a derived class seems to "expand" the base class, providing 
functionality and characteristics that the base class did not provide. 
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Even if the addition of such methods and properties to a derived class could be 
considered to somehow restrict the base class, this would not lead to the conclusion that 
the derived class was a wrapper class that encapsulated the base class. Inheriting from, or 
being derived from, a base class is not the same as encapsulating the base class. A 
derived class does not "encapsulate" or contain the base class from which the derived 
class is derived. 

On page 296, Taylor discloses that legacy systems can be "absorbed" by making 
the legacy systems appear to be object-oriented, and that this may be accomplished by 
putting object-oriented wrappers around the legacy systems to allow the legacy systems 
to interact in an object-oriented environment. Taylor fiuther discloses, on page 296, that 
wrappers can accept messages from other objects, call on conventional software to 
perform requested operations, and return results to the calling objects. 

Even taking into account all that Taylor discloses, there is no teaching or 
suggestion in Taylor or any of the cited references that such legacy systems are base 
classes or that the wrappers are in any way classes that are derived from the legacy 
systems. Indeed, if the legacy systems disclosed in Taylor were object-oriented classes at 
all, then there would not be any need to encapsulate those legacy systems within 
wrappers, because instances of object-oriented classes already can interact in an object- 
oriented environment. 

Furthermore, the wrappers discussed in Taylor do not appear in any way to 
"restrict" the legacy systems that those wrappers contain. Indeed, the wrappers appear to 
be designed to enable continued interaction with all of the features that the legacy 
systems originally provided. During the aforementioned interview, Applicant's attorney 
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asked the Examiner how the wrappers could be considered to "restrict" the legacy 
systems, and the Examiner opined that the wrappers restricted the legacy systems because 
a derived class allegedly restricts a base class from which the derived class is derived. 
However, as is discussed above, (a) an instance of such a derived class does not "restrict" 
such a base class, and (b) the legacy systems contained within the wrappers are not "base 
classes" from which the wrappers are derived anyway. 

The features recited in Claim 1 1 are not well known principles of object-oriented 
programming and design. Neither Taylor nor Pressman discloses, teaches, or suggests 
"determining a set of zero or more restrictions to be imposed on said customized 
implementation" or "instantiating a wrapper class to give rise to a wrapper instance, said 
wrapper instance comprising enforcement logic for enforcing said restrictions." As 
is discussed above, even if Taylor's legacy systems are alleged to be "customized 
implementations" and Taylor's "wrappers" are alleged to be "wrapper instances," the 
wrappers still do not comprise enforcement logic for enforcing restrictions on the legacy 
systems that they contain. The Examiner still has not demonstrated in what way Taylor's 
wrappers may be considered to "restrict" Taylor's legacy systems. 

Based on the foregoing, it is respectfully submitted that the Examiner has failed to 
show that Taylor and Pressman in any way disclose or suggest at least two of the 
limitations of Claim 11, namely, the limitations of "determining a set of zero or more 
restrictions to be imposed on said customized implementation" and "instantiating a 
wrapper class to give rise to a wrapper instance, said wrapper instance comprising 
enforcement logic for enforcing said restrictions." Since the Examiner has failed to 
show that Taylor or Pressman, taken alone or in combination, disclose or suggest all of 
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the limitations required by Claim 1 1, it is respectfully submitted that the Examiner has 
erred in rejecting Claim 11, and that Claim 1 1 is patentable over Taylor and Pressman. 

In order for a prima facie case of obviousness to be established under 35 U.S.C. 
103, the combined references must, at least when considered in combination, teach or 
suggest all of the limitations of the claims that are alleged to be obvious. The burden is 
placed upon the Examiner to make out this case by pointing out specific teachings of 
cited references. Such specific teachings might, if correct, constitute the evidence that is 
required to make out the case. However, instead of pointing out specific teachings, the 
Examiner has only named some references and then generally alleged that all of the 
limitations of Claim 1 1 are shown somewhere within the references, or are well known. 

Appellant respectfully submits that such general allegations lack the specificity 
that is required to make out a prima facie case of obviousness. At the moment, it is not 
even clear which of the references the Office Action relies upon to allegedly teach or 
suggest particular features of Claim 11. Appellant respectfully submits that a prima facie 
case of obviousness requires more that just a bare and general assertion that everything 
recited in a claim is well known. If all of the features of Claim 1 1 are as well known as 
the Examiner alleges, then it should be a simple matter for the Examiner to provide 
specific citations to pages, paragraphs, and lines that demonstrate each feature of Claim 
1 1 specifically. Yet, the Examiner has not done so. 

Claims 12-23, 70-72, and 79-87 depend fi-om Claim 1 1 and include all of the 
limitations of Claim 11. It is therefore respectfully submitted that Claims 12-23, 70-72, 
and 79-87 are patentable over Taylor and Pressman for at least the reasons set forth 
herein with respect to Claim 11. 
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Claims 34-46, 73-75, and 88-96 contain limitations similar to Claims 1 1-23, 70- 
72, and 79-87, except in the context of a framework. It is therefore respectfully 
submitted that Claims 1 1-23, 70-72, and 79-87 are patentable over Taylor and Pressman 
for at least the reasons set forth herein with respect to Claims 1 1-23, 70-72, and 79-87. 

Claims 57-69, 76-78, and 97-105 contain limitations similar to Claims 1 1-23, 70- 
72, and 79-87, except in the context of a computer-readable medium. It is therefore 
respectfully submitted that Claims 57-69, 76-78, and 97-105 are patentable over Taylor 
and Pressman for at least the reasons set forth herein with respect to Claims 1 1-23, 70-72, 
and 79-87. 

For at least these reasons, it is respectfully submitted that Claims 1 1-23, 34-46, 
and 57-105 are not in any way taught or suggested by Taylor or Pressman, alone or in 
combination, and are therefore patentable over Taylor and Pressman. 

C. The Limitations of Claims 13, 14. 16. 17, 20-23, 36, 37, 39. 40. 43-46, 59, 60. 
62. 63. 66-69, 81. 82. 90. 91. 99, and 100 Are Not in Anv Wav Taught or 
Suggested by Taylor, Pressman, and Shanton 

Claims 13, 14, 16, 17, 20-23, 81, and 82 depend from Claim 1 1 and therefore 
include all of the distinguished limitations of Claim 11. Thus, if Claim 1 1 is patentable 
over Taylor, Pressman, and Shanton, then Claims 13, 14, 16, 17, 20-23, 81, and 82 are 
also patentable over Taylor, Pressman, and Shanton. 

Like Taylor and Pressman, Shanton does not disclose, teach, or suggest at least 
the following limitations of Claim 1 1 : "determining a set of zero or more restrictions to 
be imposed on said customized implementation;" and "instantiating a wrapper class to 
give rise to a wrapper instance, said wrapper instance comprising enforcement logic for 
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enforcing said restrictions." Indeed, the Office Action does not even allege that Shanton 
discloses these features. Even assuming, arguendo, that Pressman, Taylor, and Shanton 
could be combined, Pressman, Taylor and Shanton still do not teach, disclose, or suggest 
all of the limitations of Claim 11. Thus, Claim 1 1 is patentable over Pressman, Taylor, 
and Shanton, taken individually or in combination. 

Consequently, Claims 13, 14, 16, 17, 20-23, 81, and 82 are patentable over 
Pressman, Taylor, and Shanton, taken individually or in combination, for at least the 
reasons given above with reference to Claim 11. 

Claims 36, 37, 39, 40, 43-46, 90, and 91 recite frameworks that comprise 
mechanisms for performing the methods of Claims 13, 14, 16, 17, 20-23, 81, and 82, 
respectively. AppUcant submits that Claims 36, 37, 39, 40, 43-46, 90, and 91 are 
patentable over Pressman, Taylor, and Shanton for at least the reasons given above in 
connection with Claim 13, 14, 16, 17, 20-23, 81, and 82, respectively. 

Claims 59, 60, 62, 63, 66-69, 99, and 100 recite computer-readable media that 
comprise instructions for causing one or more processors to perform the methods of 
Claims 13, 14, 16, 17, 20-23, 81, and 82, respectively. Apphcant submits that Claims 59, 
60, 62, 63, 66-69, 99, and 100 are patentable over Pressman, Taylor, and Shanton for at 
least the reasons given above in connection with Claim 13, 14, 16, 17, 20-23, 81, and 82, 
respectively. 

IX. CONCLUSION AND PRAYER FOR RELIEF 

Based on the foregoing, it is respectfully submitted the rejections of Claims 11- 
23, 34-46, and 57-105 under 35 U.S.C. § 103(a) lack the requisite factual and legal bases. 
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Appellant therefore respectfully requests that the Honorable Board reverse the rejection 
of Claims 11, 12, 15, 18, 19, 34, 35, 38, 41, 42, 57, 58, 61, 64, 65, 70-80, 83-89, 92-98, 
and 101-105 under 35 U.S.C. § 103(a) over Taylor in view of Pressman, and the rejection 
of Claims 13, 14, 16, 17, 20-23, 36, 37, 39, 40, 43-46, 59, 60, 62, 63, 66-69, 81, 82, 90, 
91, 99, and 100 under 35 U.S.C. § 103(a) over Taylor in view of Pressman and Shanton. 
This is the second time that Appellant has had to appeal the rejection of the present 
appHcation to the Honorable Board; the Examiner re-opened prosecution after the last 
appeal. Appellant fervently hopes that this will be the last time. 



Respectfully submitted. 



HICKMAN PALERMO TRUONG & 
BECKER LLP 




Date: June 7, 2005 



Christian A. Nicholes 
Registration No. 50,266 



2055 Gateway Place, Suite 550 
San Jose, Califomia 95110-1089 
Tel: (408)414-1224 
Fax: (408)414-1076 
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CLAIMS APPENDIX 



1 11. In a system comprising an application, a framework, and an 

2 implementation class which provides an implementation for a particular service, a 

3 method performed by the framework, comprising: 

4 receiving a request from an application for a customized implementation of a 

5 particular service; 

6 instantiating an implementation class which provides an implementation for the 

7 particular service to give rise to an implementation instance; 

8 determining a set of zero or more restrictions to be imposed on said customized 

9 implementation; 

10 instantiating a wrapper class to give rise to a wrapper instance, said wrapper 

1 1 instance comprising enforcement logic for enforcing said restrictions; 

12 encapsulating said implementation instance and said restrictions within said 

13 wrapper instance; and 

14 providing said wrapper instance to the application as said customized 

1 5 implementation; 

1 6 wherein said wrapper instance comprises one or more invocable methods, 

1 7 wherein said implementation instance comprises one or more invocable methods, and 

18 wherein encapsulating comprises: 

19 mapping the one or more invocable methods of said wrapper instance to the one 

20 or more invocable methods of said implementation instance. 
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1 12. The method of claim 1 1 , wherein instantiating the implementation class 

2 comprises: 

3 detemiining whether the implementation class is authentic; and 

4 in response to a determination that the implementation class is authentic, 

5 instantiating the implementation class to give rise to said implementation instance. 

1 13. The method of claim 12, wherein the implementation class has a digital 

2 signature associated therewith, and wherein determining whether the implementation 

3 class is authentic comprises: 

4 verifying said digital signature. 

1 14. The method of claim 12, wherein the implementation class authenticates 

2 the framework prior to giving rise to said implementation instance. 

1 15. The method of claim 1 1 , wherein determining the set of zero or more 

2 restrictions comprises: 

3 accessing information specifying one or more limitations; and 

4 processing said limitations to derive said restrictions. 

1 16. The method of claim 15, wherein the particular service is an 

2 encryption/decryption service, and wherein said information comprises a set of one or 

3 more default encryption limitations. 
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1 17. The method of claim 16, wherein said default encryption limitations are 

2 derived by merging multiple jurisdiction poUcies and extracting therefrom the most 

3 restrictive encryption limitations. 

1 18. The method of claim 1 1 , wherein determining the set of zero or more 

2 restrictions comprises: 

3 accessing information specifying one or more limitations; 

4 determining permissions, if any, granted to the application; and 

5 reconciling said limitations and said permissions to derive said restrictions. 

1 19. The method of claim 18, wherein said limitations and said permissions are 

2 reconciled to derive restrictions which are least restrictive. 

1 20. The method of claim 1 8, wherein the particular service is an 

2 encryption/decryption service, and wherein said information comprises a set of one or 

3 more default encryption limitations, and a set of zero or more exempt encryption 

4 limitations which apply when one or more exemption mechanisms are implemented. 

1 21. The method of claim 20, wherein said default encryption limitations and 

2 said exempt encryption limitations are derived by merging multiple jurisdiction policies 

3 and extracting therefrom the most restrictive encryption limitations. 
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1 22. The method of claim 20, wherein reconciUng said limitations and said 

2 permissions comprises; 

3 determining whether the application has been granted any permissions; and 

4 in response to a determination that the application has not been granted any 

5 permissions, deriving said restrictions from said set of default encryption limitations. 

1 23. The method of claim 20, wherein reconciling said limitations and said 

2 permissions comprises: 

3 determining whether the application has been granted any permissions which 

4 require implementation of a particular exemption mechanism; 

5 in response to a determination that the application has been granted a permission 

6 which requires implementation of a particular exemption mechanism, determining 

7 whether said exempt encryption limitations allow said particular exemption mechanism 

8 to be implemented; and 

9 in response to a determination that said exempt encryption limitations allow said 

10 particular exemption mechanism to be implemented, deriving said restrictions from said 

1 1 set of exempt encryption limitations. 

1 34. In a system comprising an application and an implementation class which 

2 provides an implementation for a particular service, a framework comprising: 

3 a mechanism for receiving a request from an application for a customized 

4 implementation of a particular service; 
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5 a mechanism for instantiating an implementation class which provides an 

6 implementation for the particular service to give rise to an implementation instance; 

7 a mechanism for determining a set of zero or more restrictions to be imposed on 

8 said customized implementation; 

9 a mechanism for instantiating a wrapper class to give rise to a wrapper instance, 

10 said wrapper instance comprising enforcement logic for enforcing said restrictions; 

1 1 a mechanism for encapsulating said implementation instance and said restrictions 

12 within said wrapper instance; and 

13 a mechanism for providing said wrapper instance to the application as said 

14 customized implementation; 

15 wherein said wrapper instance comprises one or more invocable methods, 

16 wherein said implementation instance comprises one or more invocable methods, and 

1 7 wherein the mechanism for encapsulating comprises; 

18 a mechanism for mapping the one or more invocable methods of said wrapper 

1 9 instance to the one or more invocable methods of said implementation instance. 

1 35. The framework of claim 34, wherein the mechanism for instantiating the 

2 implementation class comprises: 

3 a mechanism for determining whether the implementation class is authentic; and 

4 a mechanism for instantiating, in response to a determination that the 

5 implementation class is authentic, the implementation class to give rise to said 

6 implementation instance. 
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1 36. The framework of claim 35, wherein the implementation class has a digital 

2 signature associated therewith, and wherein the mechanism for determining whether the 

3 implementation class is authentic comprises: 

4 a mechanism for verifying said digital signature. 

1 37. The framework of claim 35, wherein the implementation class 

2 authenticates the framework prior to giving rise to said implementation instance. 

1 38. The framework of claim 34, wherein the mechanism for determining the 

2 set of zero or more restrictions comprises: 

3 a mechanism for accessing information specifying one or more limitations; and 

4 a mechanism for processing said limitations to derive said restrictions. 

1 39. The framework of claim 38, wherein the particular service is an 

2 encryption/decryption service, and wherein said information comprises a set of one or 

3 more default encryption limitations. 

1 40. The framework of claim 39, wherein said default encryption limitations 

2 are derived by merging multiple jurisdiction poHcies and extracting therefrom the most 

3 restrictive encryption limitations. 

1 41. The framework of claim 34, wherein the mechanism for determining the 

2 set of zero or more restrictions comprises: 

3 a mechanism for accessing information specifying one or more limitations; 
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4 a mechanism for deteraiining pemiissions, if any, granted to the appHcation; and 

5 a mechanism for reconciling said Hmitations and said permissions to derive said 

6 restrictions. 

1 42. The framework of claim 41, wherein said limitations and said permissions 

2 are reconciled to derive restrictions which are least restrictive. 

1 43. The framework of claim 41, wherein the particular service is an 

2 encryption/decryption service, and wherein said information comprises a set of one or 

3 more default encryption limitations, and a set of zero or more exempt encryption 

4 limitations which apply when one or more exemption mechanisms are implemented. 

1 44. The framework of claim 43, wherein said default encryption limitations 

2 and said exempt encryption limitations are derived by merging multiple jurisdiction 

3 policies and extracting therefrom the most restrictive encryption limitations. 

1 45. The framework of claim 43, wherein the mechanism for reconciling said 

2 limitations and said permissions comprises: 

3 a mechanism for determining whether the application has been granted any 

4 permissions; and 

5 a mechanism for deriving, in response to a determination that the application has 

6 not been granted any permissions, said restrictions from said set of default encryption 

7 limitations. 
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1 46. The framework of claim 43, wherein the mechanism for reconcihng said 

2 Umitations and said permissions comprises: 

3 a mechanism for determining whether the application has been granted any 

4 permissions which require implementation of a particular exemption mechanism; 

5 a mechanism for determining, in response to a determination that the application 

6 has been granted a permission which requires implementation of a particular exemption 

7 mechanism, whether said exempt encryption limitations allow said particular exemption 

8 mechanism to be implemented; and 

9 a mechanism for deriving, in response to a determination that said exempt 

10 encryption limitations allow said particular exemption mechanism to be implemented, 

1 1 said restrictions from said set of exempt encryption limitations. 

1 57. hi a system comprising an application and an implementation class which 

2 provides an implementation for a particular service, a computer readable medium having 

3 stored thereon instructions which, when executed by one or more processors, cause the 

4 one or more processors to implement a framework which dynamically constructs a 

5 customized implementation, said computer readable medium comprising: 

6 instructions for causing one or more processors to receive a request from an 

7 application for a customized implementation of a particular service; 

8 instructions for causing one or more processors to instantiate an implementation 

9 class which provides an implementation for the particular service to give rise to an 
1 0 implementation instance; 
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1 1 instractions for causing one or more processors to determine a set of zero or more 

12 restrictions to be imposed on said customized implementation; 

13 instructions for causing one or more processors to instantiate a wrapper class to 

14 give rise to a wrapper instance, said wrapper instance comprising enforcement logic for 

15 enforcing said restrictions; 

16 instructions for causing one or more processors to encapsulate said 

17 implementation instance and said restrictions within said wrapper instance; and 

1 8 instructions for causing one or more processors to provide said wrapper instance 

19 to the application as said customized implementation; 

20 wherein said wrapper instance comprises one or more invocable methods, 

2 1 wherein said implementation instance comprises one or more invocable methods, and 

22 wherein the instructions for causing one or more processors to encapsulate comprises: 

23 instructions for causing one or more processors to map the one or more invocable 

24 methods of said wrapper instance to the one or more invocable methods of said 

25 implementation instance. 

1 58. The computer readable medium of claim 57, wherein the instructions for 

2 causing one or more processors to instantiate the implementation class comprises: 

3 instructions for causing one or more processors to determine whether the 

4 implementation class is authentic; and 

5 instructions for causing one or more processors to instantiate, in response to a 

6 determination that the implementation class is authentic, the implementation class to give 

7 rise to said implementation instance. 
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1 59. The computer readable medium of claim 58, wherein the implementation 

2 class has a digital signature associated therewith, and wherein the instructions for causing 

3 one or more processors to determine whether the implementation class is authentic 

4 comprises: 

5 instructions for causing one or more processors to verify said digital signature. 

1 60. The computer readable medium of claim 58, wherein the implementation 

2 class authenticates the framework prior to giving rise to said implementation instance. 

1 61. The computer readable medium of claim 57, wherein the instructions for 

2 causing one or more processors to determine the set of zero or more restrictions 

3 comprises: 

4 instructions for causing one or more processors to access information specifying 

5 one or more limitations; and 

6 instructions for causing one or more processors to process said limitations to 

7 derive said restrictions. 

1 62. The computer readable medium of claim 6 1 , wherein the particular service 

2 is an encryption/decryption service, and wherein said information comprises a set of one 

3 or more default encryption limitations. 
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1 63. The computer readable medium of claim 62, wherein said default 

2 encryption limitations are derived by merging multiple jurisdiction policies and 

3 extracting therefrom the most restrictive encryption limitations. 

1 64. The computer readable medium of claim 57, wherein the instructions for 

2 causing one or more processors to determine the set of zero or more restrictions 

3 comprises: 

4 instructions for causing one or more processors to access information specifying 

5 one or more limitations; 

6 instructions for causing one or more processors to determine permissions, if any, 

7 granted to the application; and 

8 instructions for causing one or more processors to reconcile said limitations and 

9 said permissions to derive said restrictions. 

1 65. The computer readable medium of claim 64, wherein said limitations and 

2 said permissions are reconciled to derive restrictions which are least restrictive. 

1 66. The computer readable medium of claim 64, wherein the particular service 

2 is an encryption/decryption service, and wherein said information comprises a set of one 

3 or more default encryption limitations, and a set of zero or more exempt encryption 

4 limitations which apply when one or more exemption mechanisms are implemented. 

1 67. The computer readable medium of claim 66, wherein said default 

2 encryption limitations and said exempt encryption limitations are derived by merging 
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4 



multiple jurisdiction policies and extracting therefrom the most restrictive encryption 
limitations. 



1 68. The computer readable medium of claim 66, wherein the instructions for 

2 causing one or more processors to reconcile said limitations and said permissions 

3 comprises: 

4 instructions for causing one or more processors to determine whether the 

5 apphcation has been granted any permissions; and 

6 instructions for causing one or more processors to derive, in response to a 

7 determination that the application has not been granted any permissions, said restrictions 

8 from said set of default encryption limitations. 



1 69. The computer readable medium of claim 66, wherein the instructions for 

2 causing one or more processors to reconcile said limitations and said permissions 

3 comprises: 

4 instructions for causing one or more processors to determine whether the 

5 application has been granted any permissions which require implementation of a 

6 particular exemption mechanism; 

7 instructions for causing one or more processors to determine, in response to a 

8 determination that the application has been granted a permission which requires 

9 implementation of a particular exemption mechanism, whether said exempt encryption 
10 limitations allow said particular exemption mechanism to be implemented; and 
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1 1 instructions for causing one or more processors to derive, in response to a 

12 determination that said exempt encryption limitations allow said particular exemption 

13 mechanism to be implemented, said restrictions from said set of exempt encryption 

14 limitations. 

1 70. The method of claim 1 1 , wherein determining said set of zero or more 

2 restrictions includes determining a set of zero or more restrictions that are specific to said 

3 application. 

1 71. The method of claim 70, wherein determining said set of zero or more 

2 restrictions that are specific to said application includes determining a set of zero or more 

3 restrictions that are customized for said application. 

1 72. The method of claim 11, wherein said set is a first set, and wherein said 

2 customized implementation is a first customized implementation, and further comprising: 

3 receiving a request from a second application for a second customized 

4 implementation of said particular service, wherein said second customized 

5 implementation differs from said first customized implementation; 

6 instantiating said implementation class which provides said implementation for 

7 said particular service to give rise to a second implementation instance; 

8 determining a second set of zero or more restrictions to be imposed on said 

9 second customized implementation, wherein said second set differs from said first set; 
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10 instantiating said wrapper class to give rise to a second wrapper instance, said 

1 1 second wrapper instance comprising enforcement logic for enforcing said second set of 

1 2 zero or more restrictions; 

13 encapsulating said second implementation instance and said second set of zero or 

14 more restrictions within said second wrapper instance; and 

15 providing said second wrapper instance to said second application as said second 

1 6 customized implementation. 

1 73. The framework of claim 34, wherein said mechanism for determining said 

2 set of zero or more restrictions includes a mechanism for determining a set of zero or 

3 more restrictions that are specific to said appHcation. 

1 74. The framework of claim 73, wherein said mechanism for determining said 

2 set of zero or more restrictions that are specific to said application includes a mechanism 

3 for determining a set of zero or more restrictions that are customized for said application. 

1 75. The framework of claim 34, wherein said set is a first set, and wherein 

2 said customized implementation is a first customized implementation, and fiirther 

3 comprising: 

4 a mechanism for receiving a request from a second application for a second 

5 customized implementation of said particular service, wherein said second customized 

6 implementation differs from said first customized implementation; 

7 a mechanism for instantiating said implementation class which provides said 

8 implementation for said particular service to give rise to a second implementation 

9 instance; 
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10 a mechanism for detemiining a second set of zero or more restrictions to be 

1 1 imposed on said second customized implementation, wherein said second set differs from 

12 said first set; 

13 a mechanism for instantiating said wrapper class to give rise to a second wrapper 

14 instance, said second wrapper instance comprising enforcement logic for enforcing said 

15 second set of zero or more restrictions; 

16 a mechanism for encapsulating said second implementation instance and said 

1 7 second set of zero or more restrictions within said second wrapper instance; and 

18 a mechanism for providing said second wrapper instance to said second 

19 application as said second customized implementation. 

1 76. The computer readable medium of claim 57, wherein said instructions for 

2 determining said set of zero or more restrictions include instructions for determining a set 

3 of zero or more restrictions that are specific to said application. 

1 77. The computer readable medium of claim 76, wherein said instructions for 

2 determining said set of zero or more restrictions that are specific to said application 

3 include instructions for determining a set of zero or more restrictions that are customized 

4 for said application. 

1 78. The computer readable medium of claim 57, wherein said set is a first set, 

2 and wherein said customized implementation is a first customized implementation, and 

3 further comprising: 
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4 instructions for receiving a request from a second application for a second 

5 customized implementation of said particular service, wherein said second customized 

6 implementation differs from said first customized implementation; 

7 instructions for instantiating said implementation class which provides said 

8 implementation for said particular service to give rise to a second implementation 

9 instance; 

10 instructions for determining a second set of zero or more restrictions to be 

1 1 imposed on said second customized implementation, wherein said second set differs from 

12 said first set; 

13 instructions for instantiating said wrapper class to give rise to a second wrapper 

14 instance, said second wrapper instance comprising enforcement logic for enforcing said 

15 second set of zero or more restrictions; 

16 instructions for encapsulating said second implementation instance and said 

17 second set of zero or more restrictions within said second wrapper instance; and 

1 8 instructions for providing said second wrapper instance to said second application 

19 as said second customized implementation. 

1 79. The method of claim 11, wherein said wrapper instance is invocable by 

2 the application without fiirther interaction with the framework. 

1 80. The method of claim 1 1 , wherein the implementation class provides an 

2 unrestricted implementation for the particular service. 
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1 81. The method of claim 80, wherein the particular service is an 

2 encryption/decryption service, and v^herein the unrestricted implementation provided by 

3 the implementation class is capable of using unlimited encryption/decryption parameters. 

1 82. The method of claim 8 1 , wherein the unrestricted implementation 

2 provided by the implementation class is capable of using encryption/decryption keys of 

3 any size. 



1 83. The method of claim 1 1, wherein said enforcement logic enforces said 

2 restrictions on said implementation instance. 

1 84. The method of claim 83, wherein said enforcement logic enforces said 

2 restrictions on said implementation instance by: 

3 receiving a set of desired parameters from the application; 

4 determining whether the desired parameters exceed said restrictions; and 

5 in response to a determination that the desired parameters exceed said restrictions, 

6 preventing said implementation instance from operating. 

1 85. The method of claim 84, wherein said enforcement logic is invoked upon 

2 initialization of said wrapper instance. 
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1 86. The method of claim 1 1 , wherein the system further comprises an 

2 exemption mechanism class which provides an implementation for a particular exemption 

3 mechanism, and wherein said method further comprises: 

4 instantiating the exemption mechanism class to give rise to an exemption 

5 mechanism instance; and 

6 encapsulating said exemption mechanism instance within said wrapper instance. 

1 87. The method of claim 86, wherein said enforcement logic is invoked upon 

2 initialization of said wrapper instance, and when invoked, said enforcement logic: 

3 determines whether said exemption mechanism instance has been invoked; and 

4 in response to a determination that said exemption mechanism instance has not 

5 been invoked, preventing said implementation instance from operating. 

1 88. The framework of claim 34, wherein said wrapper instance is invocable by 

2 the application without further interaction with the framework. 

1 89. The framework of claim 34, wherein the implementation class provides an 

2 unrestricted implementation for the particular service. 

1 90. The framework of claim 89, wherein the particular service is an 

2 encryption/decryption service, and wherein the unrestricted implementation provided by 

3 the implementation class is capable of using unlimited encryption/decryption parameters. 
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1 91 . The framework of claim 90, wherein the um-estricted implementation 

2 provided by the implementation class is capable of using encryption/decryption keys of 

3 any size. 

1 92. The framework of claim 34, wherein said enforcement logic enforces said 

2 restrictions on said implementation instance. 

1 93. The framework of claim 92, wherein said enforcement logic enforces said 

2 restrictions on said implementation instance by: 

3 receiving a set of desired parameters from the application; 

4 determining whether the desired parameters exceed said restrictions; and 

5 in response to a determination that the desired parameters exceed said restrictions, 

6 preventing said implementation instance from operating. 

1 94. The framework of claim 93, wherein said enforcement logic is invoked 

2 upon initialization of said wrapper instance. 

1 95. The framework of claim 34, wherein the system further comprises an 

2 exemption mechanism class which provides an implementation for a particular exemption 

3 mechanism, and wherein said framework further comprises: 

4 a mechanism for instantiating the exemption mechanism class to give rise to an 

5 exemption mechanism instance; and 
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6 a mechanism for encapsulating said exemption mechanism instance within said 

7 wrapper instance. 

m 

1 96. The framework of claim 95, wherein said enforcement logic is invoked 

2 upon initialization of said wrapper instance, and when invoked, said enforcement logic: 

3 determines whether said exemption mechanism instance has been invoked; and 

4 in response to a determination that said exemption mechanism instance has not 

5 been invoked, preventing said implementation instance from operating. 

1 97. The computer readable medium of claim 57, wherein said wrapper 

2 instance is invocable by the application without further interaction with the framework. 

1 98. The computer readable medium of claim 57, wherein the implementation 

2 class provides an unrestricted implementation for the particular service. 

1 99. The computer readable medium of claim 98, wherein the particular service 

2 is an encryption/decryption service, and wherein the unrestricted implementation 

3 provided by the implementation class is capable of using unhmited encryption/decryption 

4 parameters. 

1 100. The computer readable medium of claim 99, wherein the unrestricted 

2 implementation provided by the implementation class is capable of using 

3 encryption/decryption keys of any size. 
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1 101 . The computer readable medium of claim 57, wherein said enforcement 

2 logic enforces said restrictions on said implementation instance. 

1 102. The computer readable medium of claim 101, wherein said enforcement 

2 logic enforces said restrictions on said implementation instance by: 

3 receiving a set of desired parameters from the appUcation; 

4 determining whether the desired parameters exceed said restrictions; and 

5 in response to a determination that the desired parameters exceed said restrictions, 

6 preventing said implementation instance from operating. 

1 103. The computer readable medium of claim 102, wherein said enforcement 

2 logic is invoked upon initialization of said wrapper instance. 

1 104. The computer readable medium of claim 57, wherein the system further 

2 comprises an exemption mechanism class which provides an implementation for a 

3 particular exemption mechanism, and wherein said computer readable medium fiirther 

4 comprises: 

5 instructions for causing one or more processors to instantiate the exemption 

6 mechanism class to give rise to an exemption mechanism instance; and 

7 instructions for causing one or more processors to encapsulate said exemption 

8 mechanism instance within said wrapper instance. 
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105. The computer readable medium of claim 104, wherein said enforcement 
logic is invoked upon initialization of said wrapper instance, and when invoked, said 
enforcement logic: 

determines whether said exemption mechanism instance has been invoked; and 
in response to a determination that said exemption mechanism instance has not 
been invoked, preventing said implementation instance from operating. 
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